[IMP] data: align data versions to release versions #5973
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
LucasLefevre
force-pushed
the
master-upgrade-odoo-lul
branch
3 times, most recently
from
667257c to
977f2a2
Compare
Task: 4659206
LucasLefevre
force-pushed
the
master-upgrade-odoo-lul
branch
from
977f2a2 to
e0ff365
Compare
LucasLefevre
commented
Mar 19, 2025
| @@ -2,555 +2,188 @@ import { toZone } from "../../src/helpers/index"; | |||
|
|
|||
| export const pivotModelData = function (xc: string) { | |||
| return { | |||
| version: 19, | |||
| version: 25, | |||
There was a problem hiding this comment.
not strictly necessary, but I realized it after it was done so... 🤷♂️
| migrate: (data: any) => any; | ||
| } | ||
|
|
||
| export function getCurrentVersion() { |
There was a problem hiding this comment.
technically, it's not the "current" version if there was no changes in one saas. Should it be rather named getLatestVersion ? or is it more confusing and getCurrentVersion is clearer even if it's not strictly speaking 100% correct in all cases?
There was a problem hiding this comment.
Should we add an empty migration step if there is no changes in one saas version to keep consistency ?
There was a problem hiding this comment.
In practice, I think we won't do it
There was a problem hiding this comment.
Except if we add it to the freeze checklist :D
LucasLefevre
force-pushed
the
master-upgrade-odoo-lul
branch
9 times, most recently
from
2b6df03 to
2d25706
Compare
pro-odoo
approved these changes
Mar 27, 2025
| migrate: (data: any) => any; | ||
| } | ||
|
|
||
| export function getCurrentVersion() { |
There was a problem hiding this comment.
Should we add an empty migration step if there is no changes in one saas version to keep consistency ?
|
Typo in the first commit => |
This commit fixes two issues at once. Issue 1 ------- Currently, the migration process will ONLY run if the version of the original data (in json) is smaller than the last version set in the source code (`CURRENT_VERSION`). This means that any additional step set outside of the library is not run without incrementing CURRENT_VERSION in o-spreadsheet. Example: - we bump the latest version to 25 in o-spreadsheet; - we push that value in Odoo - users start creating spreadsheets in that version so their spreadsheets are set to version 25 - later on, we need to add a migration step for whatever reason in Odoo, we assign it to 25.1 => the migration code will check against the latest version in the source (25) vs the one in the spreadsheet data (25 as well) and will simply skip the migration. So 25.1 will never run... Issue 2 ------- The current scheme of the incremented integer is impractical when it comes to figure out which odoo version it matches(*). Knowing the release version is usefull for bug fixes to know which version of the code generated the json data. With this commit, data format version are now aligned with odoo versions Current master is 18.3. Next, it'll be 18.4, 19.0, 19.1, etc. (*) o-spreadsheet releases follow the same version numbers as odoo releases. Task: 4659206
LucasLefevre
force-pushed
the
master-upgrade-odoo-lul
branch
from
2d25706 to
588f986
Compare
|
Merge method set to rebase and fast-forward. |
robodoo
pushed a commit
that referenced
this pull request
Mar 27, 2025
Task: 4659206 Part-of: #5973 Signed-off-by: Pierre Rousseau (pro) <[email protected]>
robodoo
pushed a commit
that referenced
this pull request
Mar 27, 2025
This commit fixes two issues at once. Issue 1 ------- Currently, the migration process will ONLY run if the version of the original data (in json) is smaller than the last version set in the source code (`CURRENT_VERSION`). This means that any additional step set outside of the library is not run without incrementing CURRENT_VERSION in o-spreadsheet. Example: - we bump the latest version to 25 in o-spreadsheet; - we push that value in Odoo - users start creating spreadsheets in that version so their spreadsheets are set to version 25 - later on, we need to add a migration step for whatever reason in Odoo, we assign it to 25.1 => the migration code will check against the latest version in the source (25) vs the one in the spreadsheet data (25 as well) and will simply skip the migration. So 25.1 will never run... Issue 2 ------- The current scheme of the incremented integer is impractical when it comes to figure out which odoo version it matches(*). Knowing the release version is usefull for bug fixes to know which version of the code generated the json data. With this commit, data format version are now aligned with odoo versions Current master is 18.3. Next, it'll be 18.4, 19.0, 19.1, etc. (*) o-spreadsheet releases follow the same version numbers as odoo releases. closes #5973 Task: 4659206 Signed-off-by: Pierre Rousseau (pro) <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description:
This commit fixes two issues at once.
Issue 1
Currently, the migration process will ONLY run if the version of the original
data (in json) is smaller than the last version set in the source code
(
CURRENT_VERSION). This means that any additional step set outside of thelibrary is not run without incrementing CURRENT_VERSION in o-spreadsheet.
Example:
set to version 25
assign it to 25.1
=> the migration code will check against the latest version in the source (25)
vs the one in the spreadsheet data (25 as well) and will simply skip the
migration.
So 25.1 will never run...
Issue 2
The current scheme of the incremented integer is impractical when it comes
to figure out which odoo version it matches(*).
Knowing the release version is usefull for bug fixes to know which version of
the code generated the json data.
With this commit, data format version are now aligned with odoo versions
Current master is 18.3. Next, it'll be 18.4, 19.0, 19.1, etc.
(*) o-spreadsheet releases follow the same version numbers as odoo releases.
Task: 4659206
review checklist